home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 11 / Cream of the Crop 11-2.iso / os2 / rsynth1.zip / PORTING < prev    next >
Text File  |  1994-11-01  |  2KB  |  62 lines
  1. Hopefully most of unix/compiler variant issues should be handled by configure
  2. process. Thus porting issues should reduce (for UNIX-ish machines at least)
  3. to writing the audio driver.
  4.  
  5. The interface to the driver is defined in hplay.h.
  6. There are three routines:
  7.  
  8. extern int audio_init PROTO((int argc, char *argv[]));
  9.  
  10.  Do what ever is necessary to initialize audio.
  11.  You can process any command line arguments to influence the 
  12.  behaviour. Use getargs() function to make this easy.
  13.  Where it make sense copy options from other drivers e.g. -r for 
  14.  sample rate.
  15.  
  16.  This routine should also define the global variable samp_rate
  17.  to define sample rate to the core synth.
  18.  
  19.  Sample rates in 8 - 12kHz range work best due to as yet unresolved
  20.  problems with some of the digital filters.
  21.  
  22. extern void audio_play PROTO((int n, short *data));
  23.  
  24.  Send a block of 'n' 16 bit signed linear samples to the 
  25.  audio device. If your device requires uLaw samples (US telephone standard)
  26.  then l2u.h defines routines which may help (example is Sun driver).
  27.  
  28. extern void audio_term PROTO((void));
  29.  Close down audio device, probably waiting for buffer(s) to empty.
  30.  
  31. To test your driver (which should be called xxxxplay.c where xxxx describes
  32. the system/hardware), link it to hplay.c, and "make".
  33.  
  34. The brave/experienced  might like to obtain and install GNU autoconf-2.0 (or
  35. latter?) and the GNU m4 it needs (m4-1.3 or latter), and try and get the new
  36. driver auto configured.
  37.  
  38. When you have written your driver please contact me (nik@tiuk.ti.com)
  39. if you are willing to let others use it. Please let me know the output of
  40. config.guess  script to assist in merging into autoconf. 
  41.  
  42. ------------------------------------------------------------------------
  43.  
  44. Perfomance issues.
  45.  
  46. For best speed in parwave.c all arthmetic is done in "float",
  47. but with strict IEEE-754 compliance turned off.
  48. This is fastest because in general for modern RISC processors
  49. (e.g. SPARCs or at least some of them ...)
  50.  
  51.   - There is no integer multiply hardware
  52.   - There IS floating point multiply hardware
  53.   - Floating point multiply hardware cannot handle "double" in one pass.
  54.   - Some of IEEE-754 options (e.g. denormals) are handled via software traps.
  55.  
  56. This may be less true of x86/68xxx machines...
  57.  
  58. The computations in parwave.c should dominate the cpu requirements
  59. of the other levels.
  60.  
  61.  
  62.